The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
The number and size of peer-to-peer data communications networks operating in connection with the public internetworks known as the Internet have grown rapidly in recent years. At the time of this writing, some studies estimate that at least half of all Internet bandwidth consumption is peer-to-peer traffic. Examples of peer-to-peer networks include those using Fast Track, eDonkey, Gnutella, BitTorrent, and research networks such as Chord and Tapestry.
The explosive growth of peer-to-peer traffic presents problems for Internet Service Provider (ISP) enterprises, because Internet routing infrastructure elements and related computing elements have not been designed to accommodate the massive amounts of data that are being exchanged among peer-to-peer hosts. In various implementations, peer-to-peer hosts hold resources for delivery on request to other hosts, or execute applications that can service requests from other hosts.
A typical peer-to-peer network is implemented using software nodes that conceptually are overlaid on top of a network of hardware nodes, such as routers and switches, which use Internet Protocol and related protocols for inter-node network communication. In this arrangement, the peer-to-peer nodes do not receive information about network topology and traffic dynamics.
In certain deployments, the routers and switches may use deep packet inspection or Application-Oriented Network System (AONS) approaches to learn that the routers or switches are carrying peer-to-peer traffic. However, these approaches are not widely deployed, and cannot affect how the peer-to-peer nodes select resource locations, select resource replicas, send traffic to other peer nodes, or perform other tasks.
Because peer-to-peer nodes and applications presently ignore underlying network topology and data processing characteristics, peer-to-peer users may not receive the best possible experience. For example, peer-to-peer content might be served from hosts that do not have optimal network reachability, or network-attached resources might not be used optimally.
The expanding use of peer-to-peer networks also imposes significant new costs on ISPs as a result of certain characteristics of peer-to-peer protocols. For example, when a peer that uses the BitTorrent protocol requests content, standard BitTorrent tracker nodes return a list of randomly selected peer nodes that have the requested content. The optimal performance of BitTorrent derives, in part, from the randomness of peer selection. The requesting peer node can connect to any other peer node on the list to obtain the requested content. However, if the requesting peer node is located within a first ISP network and the other peer node is in a second ISP network, the first ISP may charge the second ISP for carrying traffic that terminates in the second ISP network. There is presently no way to constrain the behavior of peer-to-peer protocols to nodes within one ISP or autonomous system. There is a need to provide such a constraint while maintaining optimal performance of peer-to-peer protocols.
Akamai, Inc. has deployed a content delivery network comprising distributed content servers. In the Akamai architecture the content servers are decoupled from the Internet in the sense that content servers do not receive routing protocol information from routers or servers that are connected to the content servers. Akamai technology does not select content servers based on routing protocol information.